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ABSTRACT 


The Electronic Warfare Integrated Reprogramming (EWIR) database is the pri¬ 
mary Department of Defense source for technical parametric performance data on non¬ 
communications emitters. It has been identified by the National Air Intelligence Center as 
difficult to use in its current hierarchical database form. There are two problems addressed 
by this thesis. First, is an object-oriented EWIR database a superior method for managing 
complex electronic warfare data collections? Second, is the prototype Object-Oriented 
Interface (O-OI) developed at the Laboratory for Database System Research in the Naval 
Postgraduate School capable of supporting a complex object-oriented database such as 
EWIR? 

To answer these questions, a subset of the EWIR Object-Oriented Specification 
developed in a separate thesis is implemented on the O-OI. Using the O-OI Data Defini¬ 
tion Language, the object-oriented EWIR database schema and its associated record data 
are stipulated and loaded to create the live database. Using the O-OI Data Manipulation 
Language, nine EWIR transactions are elaborated and executed. 

The first result of this thesis is the O-OI performs as specified, but requires addi¬ 
tional data manipulation and logical control functions to handle complex databases. The 
minimum additional functions include Insert, Delete, and If-then-else. The inheritance 
feature also requires a generalization-to-specialization data retrieval capability. The sec¬ 
ond result of this thesis is the straightforward data manipulation capability of the object- 
oriented version of the EWIR database. The object-oriented specification more accurately 
captures data relationships. The inheritance, path, and object comparison features stream¬ 
line the linkage of related data, thus simplifying ad hoc query construction. 
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I. INTRODUCTION 


The objective of our thesis is to research into the application of object-oriented 
database management for the Electronic Warfare Integrated Reprogramming (EWIR) 
data. This research is driven by the following factors: 

• Object-oriented database management is the latest database technology. 

• The effectiveness of object-oriented data management has not been realized on 

any electronic warfare data. 

• DOD representatives have requested our database reengineering research with 
object-oriented methodology and technology on the EWIR data. 

In conducting this research, the following goals are achieved: 

• Determine whether the object-oriented EWIR database is more effective, effi¬ 
cient, and intuitive for managing complex electronic warfare data collections 
than conventional database systems. 

• Evaluate the new object-oriented-data-model-and-data-language interface (for 
brief, the Object-Oriented Interface) of the Multimodel and Multilingual Data- 

base System (M DBMS) and its capability in supporting the object-oriented 
EWIR database. 

To achieve the above, this thesis consists of the specification, implementation, pro¬ 
cessing, and evaluation of a proposed object-oriented EWIR database (for brief, the new 
EWIR database). The new EWIR database is derived from the object-oriented specifica¬ 
tion of the existing EWIR database [Ref. 1]. The EWIR evaluation includes a sequence of 

object-oriented queries through the Object-Oriented Interface of the M^DBMS. 

This thesis is the second of a two-thesis project designed to transform the existing 
EWIR data into a working object-oriented database. The first thesis [Ref. 1] is responsible 
for the conceptual design of the object-oriented specification of the existing EWIR data¬ 
base. The conceptual design transforms the EWIR’s existing hierarchical and flat-file data 
collections into an object-oriented database specification. This second thesis uses the con¬ 
ceptual design of Ref. 1 to create an implementable subset of the EWIR database on the 

MODEMS. The Object-Oriented Data Definition Language (O-ODDL) is used to specify 
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and create the EWIR object-oriented database [Ref. 2]. The Object-Oriented Data Manip¬ 
ulation Language (O-ODML) is used to specify and write a series of object-oriented que¬ 
ries on the newly created object-oriented EWIR database for processing [Ref. 3]. 

In Chapter n of this thesis, an overview of the M DBMS is given. In Chapter HI, 
an examination of the existing EWIR database and the new EWIR database implemented 
in this thesis is presented. The implemented subset is in terms of a new object-oriented 
specification. In Chapter IV, an examination of the new EWIR database schema in terms 
of the O-ODDL is detailed. The new EWIR database record data is also specified. In 
Chapter V, we cover the O-ODML specification of nine transactions, their processing pur¬ 
pose, and an analysis of the returned results. In Chapter VI we have concluding remarks. 
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11. MODEMS BACKGROUND 


In this chapter, the necessary system software, language features, and supporting 
architecture are expounded. Our new object-oriented EWIR database is implemented on 

the Object-Oriented Interface of the MODEMS [Ref. 4]. To this end. Section A will pro¬ 
vide an overview of the MODEMS. 

The first step in creating the EWIR database on the Object-Oriented Interface 
involves EWIR data definition. Thus, the Object-Oriented Interface data definition process 
is examined in Section E as well as the DDL constructs. There must also exist a Data 
Manipulation Language (DML) to process the data. Data manipulation in a database is 
done via queries. How the Object-Oriented Interface processes a query and the DML con¬ 
structs are the subjects of Section C. 

Eecause MODEMS and its associated Object-Oriented Interface are research 
projects, some limitations have been designed into the system. Section D will summarize 
those limitations plus list some of the system advantages. 

A. AN OVERVIEW OF THE MODEMS 

A major goal of this thesis is to evaluate the performance of the object-oriented 
interface of the MODEMS with a complex data set, namely EWIR. An understanding of 

the unique approach that MODEMS brings to database systems design is important for two 
reasons. First, this system offers a distinct paradigm shift for accessing information across 
heterogeneous multi-databases. Second, any subsequent discussion on the design and 
implementation features of the Object-Oriented Interface must first be placed in the con¬ 
text of its host database system. 

The definition of a multi-database system includes the support of heterogeneous 

databases, each of which is based on a different data model. The MODEMS differs in that 
it is not a collection of separate data models and database languages. Instead, the 

MODEMS organizes all of its heterogeneous databases on a single data model and data 
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language. As depicted in Figure 1, this common data model and data language is called the 
database kernel. The MODEMS kernel uses the attribute-value pair as the atomic unit of 


A hierarchical db user 
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Figure 1. Data Sharing in the MODEMS - An Example of the Relational User 
Accessing Object-Oriented Data Relationally. 
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data. The attribute-value pair consists of a system generated object identifier (attribute) 
and its associated value. To distinguish one kernelized database from the other within 

M'^DBMS, we use their corresponding schemas, A database schema is a database defini¬ 
tion of the attributes and the relations in the database. The MODEMS contains a relational 
schema, hierarchial schema, network schema, functional schema, and the newly com¬ 
pleted object-oriented schema. 

The database user needs no knowledge of how the underlying system translates the 

data to a kernel format. In addition, the kernel system and schemas of the MODEMS allow 
translation to occur between heterogeneous databases within the system. For example, a 
relational user can access information from an object-oriented database in a relational 
query language. The relational schema for an object-oriented database will translate the 
object-oriented data into its relational equivalent for display. Also in Figure 1 is a concep¬ 
tual diagram of how heterogeneous database data is shared. 

B. THE DATA DEFINITION IN THE OBJECT-ORIENTED 
INTERFACE 

Because all physical data resides in the kernel, the object-oriented data model (O- 
ODM) must be mapped to its Attribute-based Data Model (ABDM) equivalent. A map¬ 
ping is a translation from one data representation to another. The mapping from object-ori¬ 
ented to ABDM is as follows; The Object-Oriented Data Definition Language (O-ODDL) 
accepts as its input the specification of an object-oriented database schema [Ref. 5]. The 
O-ODDL compiler checks the correctness of the specification via a scanner and parser. 
The scanner checks the O-ODDL statement syntax while the parser checks ensures the 
statement follows the grammatical rules of the language. The compiler also generates a 
data dictionary for use by the query constructor. The compiler descriptor and template 
files are the object-oriented specification in an equivalent kernel database. In Figure 2 is a 
diagram of the data definition process. 
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user select 0-0 interface 


query constructor 



language interface 
controller 


Figure 2. The Data Definition Process. 

The O-ODDL provides the constructs for creating a new database schema. The fol¬ 
lowing O-ODDL specifications are used by the Object-Oriented Interface to create a 
schema for an object-oriented database. 

1. The Class Specification 

A class is the grouping of objects which share common attributes and methods. 
Attributes are data types which provide value and meaning to a class. A method is a proce¬ 
dure within a class used to manipulate information. In Figure 3 is the O-ODDL template 
for the specification of a class. Methods have not been implemented on the Object-Ori- 
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ented Interface and are omitted from the class specification. 


Class C/ass name[ 


attribute JypeJ 

attributejiame_ 1 ; 

attribute type m 
}; 

attributejiamenv, 


Figure 3. The Specification of a Class. 


AttributeJype represents the domain of the attribute. The domain may be of a 
simple type, such as an integer or character, or a complex type, such as another class. The 
attribute jiame is the user assigned name of the attribute and functions as the placeholder 
for its value. 

2. The Inheritance Specification 

Inheritance is the receipt of all attributes and methods from another class. Inherit¬ 
ance is described as a hierarchy. In this hierarchy, a subclass inherits firom the superclass. 
The subclass has attributes in addition to those which were inherited. Thus, the subclass is 
a specialization of the superclass. The inheritance specification is listed in Figure 4. 
Class namel is the subclass (specialization) of Class namel (generalization). The 
attributes in this specification are unique to Class jiamel and not part of Class_name2. 


Class Class Jiamel :Inherit Class jiame2{ 
attribute Jype _1 attribute jiamel; 


attributejypejn attribute name_m', 

}; 


Figure 4. The Inheritance Specification. 


7 










3. The Cover Relationship 

Covering defines a mapping relationship between an object in a class (the cover 
class) to a set of objects in a second class (the member class). The covering specification is 
depicted in Figure 5. In this instance. Class jiamel is the cover class and Classjiamel is 
the member class. This means an object of class Class namel maps to a subset of objects 
from class C/a55 name!. 


Class Class Jiamel .Cover Class name2[ 
attribute Jype_l attribute name_1; 


attributeJypeji attribute name_2; 

}; 

Figure 5. The Cover Specification. 

4. Set Relationships 

The set relationship allows an attribute of a class to be more than just a singleton 
value. Set_of forms a one-to-many (1:N) relationship. Inverse of is the complement of 
set of and allows a many-to-many (M;N) relationship. Figure 6 specifies the set_of and 
inverse_of constmcts allowing the O-ODM to represent 1:N and M:N relationships of two 
object classes. 


set_of Classjame attributejame; 

inverse of Class name.attribute name attribute name 


Figure 6. The Specification for Set_of and Inverse_of. 
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C. THE DATA MANIPULATION IN THE OBJECT-ORIENTED 
INTERFACE 

A query uses DML constructs to manipulate data in a database. The O-ODML 
compiler delineates the language constructs used to process and execute high-level queries 
[Ref. 6]. A high-level query language specifies what data is to be manipulated rather than 
how to manipulate the data. 

In Figure 7 is a diagram of the steps involved in O-ODML compiler processing. 
First, a query expressed in a high-level query language must be scanned, parsed and vali¬ 
dated. The scanner identifies the language components (tokens) in the text of the query 
while the parser checks the query syntax to ensure it is formulated in accordance with the 
syntactical rules of the query language. The scanner builds a symbol table composed of a 
variable name, variable type, and class name. The symbol table information is required for 
later use by the query constructor. 

The parser completes an intermediate table. The intermediate table stores the perti¬ 
nent information from the query. Pertinent information includes the data manipulation 
operation to be performed and any associated arguments. Some query optimization may 
also be possible using the intermediate table data. Optimization is the reordering and 
restructuring of query information to minimize the time spent searching for data in the 
database. Ultimately, the intermediate table information is used by the query constructor. 

The query constructor extracts information stored in the Data Dictionary, Symbol 
Table, and Intermediate Table and produces as output either a nearly-executable equiva¬ 
lent transaction or a well-formed query. Nearly-executable means some of the ABDML 
statements require additional information that must be retrieved from the kernel data. 
Well-formed means aU information required to execute the query is immediately avail¬ 
able. Retrieval of any missing information is the responsibility of the Real Time Monitor. 

The Real Time Monitor accepts these nearly executable or well-formed ABDML 
statements from the query constructor and, using the data dictionary, assembles the requi¬ 
site information to create fully executable queries in the ABDBMS [Ref. 7]. The Real 
Time Monitor also sends the returned results of the query to a Kernel Formatting System 
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(KFS). The KFS puts the retrieved information in the proper format for output to the user 
[Ref. 8], 



Figure 7. Query processing. 


The O-ODML is designed for writing transactions and processing queries which 

can be executed within the MODEMS via the Object-Oriented Interface. Manipulating a 
database includes such functions as retrieving specific data, updating the database, and 
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generating reports. Typical manipulations include insertion, deletion, retrieval and modifi¬ 
cation of the data. In Ref. 3, Appendix A is the full Object-Oriented DML Users Manual 
for the Object-Oriented Interface. Important concepts of the object-oriented DML include: 

1. Object Identifiers 

Every object has a unique, system generated identifier. Identifiers uniquely label 
each data object and provide the system a means to identify and perform manipulations on 
created objects in the database. Identifiers are maintained by the system and are not avail¬ 
able to the users. 

2. Object-Oriented Operations 

Although methods are an integral part of object-orientation, the Object-Oriented 
Interface does not currently support methods for objects. The addition of method function¬ 
ality to the Object-Oriented Interface is a topic for future research on this system. 

Instead of methods, the Object-Oriented Interface uses object-oriented operations. 
Object-oriented operations are transactions defined for use on an object of the object class. 
These are not methods because they are not contained within any object class of the data¬ 
base. These operations are generic and not tied to specific data aggregates. In Figure 8 is 
an example of two operations available as listed in Table 1 of Ref. 3. 


OPERATION 

SYNTAX 

SEMANTICS 

Find_one 

find_one c/as5 name 

Searches and returns only the 



first object from class jtame 
that satisfies the expression. 

add 

add (obj_ref, attr) 

Adds an attribute, a single 
value, to a list or set of 
attributes in a cover relation. 


Figure 8. Examples of Operations. 
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3. The Query Constructs 

The Object-Oriented Interface query is a structured collection of declarations and 
operations in a block format. The object-oriented operations [Ref. 3, Table 1], the DML 
production rules [Ref. 3, Table 2], and reserved words [Ref. 3, Table 3] provide the func¬ 
tionality needed to construct high-level queries. Each query is compiled by the object-ori¬ 
ented compiler [Ref. 6]. The compiler ensures each query is formatted and structured 
within strict guidelines to be recognized as a legitimate. The format of a query is divided 
into five basic parts as illustrated in Figure 9. 



Syntax 

Semantics 

Example 

part 1: 

QUERY id IS 

Query Heading 

QUERY add_radar IS 

part 2: 

type id; 

Declarations Part 

obj_ref p; 

part 3: 

BEGIN 

Reserved word 

BEGIN 

part 4: 

statementjist. 

body of executable 
statements and ops 

p:= insert Radar; 
p.fi:eq;= 12345 

part 5: 

END; 

Reserved word 

END; 


Figure 9. Query Constructs. 


D. LIMITATIONS AND ADVANTAGES 

The MODEMS uses many of the features and constructs of object-oriented pro¬ 
gramming languages. These features include the concepts of unique objects, object 

classes, inheritance, encapsulation and covering. Because the MODEMS is a research 
project, it does not have the full range of features and functionality expected in a commer¬ 
cial product Some current limitations on the system include; 

• No methods within a class. 

• No floating-point arithmetic. 
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• Only four logical operators in a single statement. 

• Only a subset of the operations listed in Table 1 of Ref. 3 have been imple¬ 
mented. The operations currently available are find_one,find_many, display, add, 
and contains. The remaining operations are to be implemented at a later date. 

The kernel system must service several different database systems while being 
limited to an attribute-value pair format. All database functionality, as perceived by the 
user, is emulated in software above the kernel system. This makes implementation more 
complex than a simple uni-database system, but the advantage and flexibility achieved in a 
multimodel and multilingual system more than offsets the more complex implementation. 
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in. THE NEW EWIR DATABASE SPECIFICATION 


As stated in Chapter I, the implementation of the EWIR database using the Object- 
Oriented Interface is a primary objective in this theses. Thus, it is important to understand 
the background and structure of the existing EWIR database. In Section A of this chapter, 
the basic background information on the existing EWIR database is provided. In Section 
B, a comparison of the existing, non-object-oriented EWIR data model versus the object- 
oriented specification of the existing EWIR database [Ref. 1] is given. In Section C, 
implementation issues of the new EWIR database are given. In Section D, there is the 
object-oriented specification of the new EWIR database. 

A. SOME BACKGROUND ON EWIR 

The existing EWIR database is the primary Department of Defense approved 
source for technical parametric and performance data on noncommunications emitters and 
associated systems. The EWIR system provides an up-to-date and accurate source of 
information for reprogramming United States Electronic Warfare (EW) Combat Systems. 
EWIR includes parametric data on radars, jammers, navigational aids, and numerous non¬ 
communication electronic emitters. 

The EWIR database is chosen as the test database for an object-oriented imple¬ 
mentation for several reasons. First, it is a widely used, real-world application with suffi¬ 
cient complexity to adequately evaluate the versatility and utility of the Object-Oriented 
Interface. Second, the EWIR database is identified by the National Air Intelligence Center 
(NAIC) as difficult to understand and use in its current form. Third, it possesses properties 
that make it an acceptable candidate for object-orientation. These properties include easily 
identifiable objects and relationships between objects. 

Users of the present EWIR database are united in their assessment that the current 
hierarchical data model relies heavily on the users’ understanding of the data relation¬ 
ships, many of which are not explicitly depicted in the data model. In addition to the poor 
data modeling, the EWIR database format is difficult to interpret where codes are not stan- 
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dardized for all record types. Further, the database is described in terms of the physical 
storage structure. 

B. THE EWm DATA MODEL: THE OLD HIERARCHICAL VERSUS 
THE NEW OBJECT-ORIENTED 

A detailed analysis and comparison of the two EWIR data models is presented in 
Ref. 1. This thesis validates the object-oriented model of EWIR data as a vast improve¬ 
ment over the original hierarchical one by creating a live object-oriented EWIR database. 

The parametric data associated with electronic emitters in the EWIR is represented 
as a logical tree. A small part of the EWIR parametric tree is shown in Figure 10. This 
parametric tree orders a long list logically and hierarchically in a way that proceeds from 
broad characteristics through levels of successively finer ones. Parametric data exist in 
subfiles of the tree stracture. Subfiles are major groupings, or subtrees, within the para¬ 
metric tree which contains logically related data. 

linear 

polarization 

circ or ellipt 
polarization 

adaptive 
polarization 

manual 
polarization 

periodic_prog 
polarization 

polarization 
modulation 

Figure 10. The EWIR Parametric Tree. 
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The parametric tree of Figure 10 demonstrates how poorly data relationships are 
modeled. For example, the hierarchical tree structure leads you to believe that antenna 
polarization is divided into three distinct types: fixed, cross and variable. In reality, 
antenna polarization can only be fixed or variable. The cross polarization is a characteris¬ 
tic or relationship of all antennas and not a discrete type of the antenna polarization. Thus, 
semantics of the cross polarization are not captured in the model. The responsibility for an 
understanding of the cross polarization is incumbent upon the user. 

A second example of shortcomings of the current EWIR data model is the relation¬ 
ship of linear polarization to fixed polarization. Linear polarization is a potential charac¬ 
teristic of all antenna polarization types but is depicted as a part of the fixed polarization 
only. The hierarchical EWIR model again fails to accurately depict this relationship. 

The above examples of the current EWIR model show deficiencies in capturing 
essential data relationship information. Related information is often scattered over many 
relations or records. A solution to this information gap is the use of an Object-Oriented 
Data Model (O-ODM). The O-ODM supports the modeling of object stractures and inter¬ 
relationships in a natural way. The O-ODM not only supports object structural definitions, 
but also the modeling of object behaviors and their dynamic constraints. 

To illustrate the above, we present in Figure 11 an object-oriented version of the 
same subset of information as depicted in Figure 10. Notice that the polarization is divided 
into fixed and variable only. The cross polarization is depicted as an attribute of polariza¬ 
tion and not a distinct type of polarization. Also observe that the linear polarization is a 
specialization type of the antenna polarization and not strictly a subset of the fixed polar¬ 
ization. The object-oriented data model embeds these data relationships into the data 
model. The responsibility for any knowledge of data relationships is no longer incumbent 
upon the user. When integrating object-oriented concepts into a database, the end result is 
a much more intuitive, natural, and powerful database system. 
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Figure 11. The Object-Oriented Model of the EWIR Tree in Fig. 10. 


C. THE OBJECT-ORIENTED IMPLEMENTATION OF EWIR DATA 

The exhaustive examination of the entire EWIR database [Ref. 1] and its object- 
oriented modeling are beyond the scope of this thesis. Here, we derive a subset of the 
object-oriented specification of the EWIR database [Ref. 1] and implement it on 

MODEMS as a live object-oriented database using the Object-Oriented Interface. The live 
database is to evaluate and demonstrate the effectiveness of the Object-Oriented Interface 
and its ability to manage complex object-oriented data relationships. 
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Approximately 20 percent of the fully specified object-oriented EWIR database 
[Ref. 1] is implemented in this thesis. This percentage is sufficient to test the Object-Ori¬ 
ented Interface and evaluate the effectiveness of an object-oriented EWIR database sys¬ 
tem. The thesis objectives are achieved for the following reasons: 

• All of the data relationships (inheritance, 1:1,1:N, M:N) represented in the fully 
specified object-oriented EWIR database are captured in the implemented sub¬ 
set. This includes the depth of inheritance relationships and levels of data rela¬ 
tionships (i.e.,path or dot notation). 

• The scale is smaller, but the complexity of data relationships is not diminished. 
Essential classes from each major EWIR sub-section are retained to allow for 
cogent and pertinent data manipulation. Thus, it is possible to evaluate whether 
or not the Object-Oriented Interface is more effective, efficient, and intuitive for 
managing the complex data collections of EWIR. 

A change to the object-oriented specification of the existing EWIR database [Ref. 
1] is required to implement the inheritance relationship. A problem with the current 
Object-Oriented Interface is that it allows the data retrieval in an inheritance relationship 
only from a specialization class to a generalization class. In other words, if transactions are 
in a specialization class, they can retrieve information from any generalization class from 
which it inherits. However, no transaction can retrieve data in an inheritance relationship 
starting from a generalization class and attempting to retrieve information from a special¬ 
ization class from which it is inherited. 

In Ref. 1, many of the relationships involve multiple levels of inheritance. Many of 
these inheritance hierarchies have entries at the highest level of the abstraction (generali¬ 
zation). Thus, using the Object-Oriented Interface it is impossible to retrieve data from 
successive specialization classes. In referring to Figure 12(a), the following is an example 
of information which cannot be retrieved: “For a given Transmission j)ower, list an 
attribute of constant_powef\ The current Object-Oriented Interface cannot navigate 
through the database in the generalization-to-specialization direction. On the other hand, 
the Object-Oriented Interface can process the following request: “List the 
Transmission_power when constant_power.data = xyx”. This is specialization-to-gener- 
alization and the system can successfully navigate in this direction. 
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In Figure 12(b), we depict our modification in order to avoid classes that cannot be 
reached in the Object-Oriented Interface. The solution is the following: Any “leaf’ nodes 
in the object-oriented specification of the existing EWIR database [Ref. 1] which are spe¬ 
cialization classes are modified to include a 1:1 relationship with a generalization class. 
This allows an entry into the lowest-level specialization, thus providing access to data in 
all of its generalization classes. 



Figure 12. A Comparison of Object-Oriented Specifications and Object-Oriented 
Implementation. 
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D. THE NEW EWIR OBJECT-ORIENTED DATABASE 


This section is composed primarily of figures depicting the new EWIR object-ori¬ 
ented specification. In Figure 1 is the key for use in clarifying Figures 14 through 19. To 
minimize cluttering the figures, individual attributes of each class are omitted. Specific 
attribute information for each class is provided in Chapter IV. For ease of reference, 
Appendix A contains the object-oriented specification of the existing EWIR database 
[Ref. 1]. 



1. A Top-Level View of the New EWIR Database 

A top-level view of the new EWIR database shown in Figure 14. When comparing 
the new EWIR database with the object-oriented specification of the existing EWIR data- 








base [Ref. 1], the most notable difference is the density and structuring of the data classes. 
Subsequent figures illustrate details of each major subdatabase of Figure 14. What is 
important to note in Figure 14 is that all subdivisions in the object-oriented specification 
of the existing EWIR database also exist in the new EWIR database. Thus, important data 
relationships between major subdatabases of EWIR remain intact. 

One notable difference between the two data specifications is how the new EWIR 
database depicts 1:1 relationships between classes in parametric jiata and classes in all of 
the other databases. Many of the 1:1 relationships tie parametric data to the leaf nodes of 
the EWIR database. This tie-in must occur to avoid having the unreachable inheritance 
specialization classes as discussed in Chapter 11. 

2. The Antenna Data 

The antenna data form a fundamental component of an emitter. One emitter can 
have many different antenna components, and thus the emitter-antenna relationship is 
modeled as a 1:N. The antenna has a profound effect on signal characteristics throughout 
the range of EW activities. The antenna characteristics used in this thesis are but a small 
representation of the entire spectrum of antenna data. 

In Figure 15 is the depiction of the antenna classes in the new EWIR database. The 
key concepts retained fi'om the original EWIR specification [Ref. 1] are the antenna polar¬ 
ization, antenna radiation patterns, antenna scanning methods, and antenna tracking meth¬ 
ods. The classes omitted from the original specification are, for the most part, sibling 
branches in a hierarchical tree rooted at the antenna class. These sibling branches are typi¬ 
cally just variations of inheritance specializations. For example, the original specification 
[Ref. 1] for the class Scan has three inheritance specialization hierarchies - Mechanical 
scan, Manual scan, and Electronic scan (See also Appendix A). By implementing only 
Mechanical scan in the new EWIR database, an essential function of Scan is retained 
while eliminating the near-duplicate information. The ability to successfully manipulate 
data in the Mechanical_Scan inheritance hierarchy adequately validates the ability of the 
Object-Oriented Interface to manipulate all of the branches of Scan in the original EWIR 
specification. 
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Figure 15. The Antenna Specification. 


3. The EWIR Signal Data 

The Signal data form the sum and substance of the EWIR database parametric 
data. The control of the electromagnetic spectrum requires an intimate knowledge of the 
characteristics of signals produced by adversary emitters. The EWIR parametric data are 
designed to convey the emitter signal information which forms the “fingerprint” used in 
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identifying emitters. 

In deciding how to reduce signal data to an implementable size, we focus primarily 
on retaining the most useful signal information. A second priority is to retain some of the 
complex data relationships. The signal data of the EWIR database contains multiple-level 
inheritance and 1:1 relationships. By following the pulsed RF inheritance specialization of 
Signal, a four-level inheritance hierarchy is attained (See Appendix A). In Figure 16, this 
four-level inheritance is integrated into the new EWIR database. A 1:1 relationship 
between signal and both constant power and not-constant power is shown in Figure 16. 
This change from the original specification is to avoid having unreachable specialization 
classes. 

Although most of classes of signal data in are not implemented in the new EWIR 
database, the essential purpose of signal data is retained. The signal RF, power, agility, and 
structure remain in the new database. The retained classes provide adequate stracture and 
content to evaluate the merits of its object-oriented implementation. 

4. The EWIR Receiver Data 

The receiver, like the antenna, is a fundamental component of the emitter. One 
emitter can have many receivers, and the emitter-receiver relationship is therefor modeled 
as a 1 :N. The parameters of a receiver reveal an emitters’ capability to evaluate incoming 
signals. The capability is a major determinant in the emitters overall performance. 

The receiver is primarily concerned with the signal processing. Thus, the signal 
processing classes are included in the new EWIR implementation. The classes and 
attributes retained are based on the most frequently used data in the receiver subsection. 
The receiver specification of the new EWIR database is shown in Figure 17 and can be 
compared with the original object-oriented specification reproduced in Appendix A. 

5. The EWm WARM Data 

The meaning of WARM is the War Reserve Mode. Many emitters have special 
modes to be used only in a time of war. The intended purpose is to create some confusion 
about EW sources in order to gain an advantage over the enemy. Therefore, any prior 
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Figure 17. The Receiver Data. 


an enemy’s war reserve modes is of major importance. The EWIR database tracks avail¬ 
able emitter WARM data. 

The WARM data [Ref. 1], is a hub and spoke structure (See Appendix A). WARM 
is the hub and functions as the generalization class for all the spokes (i.e., the specializa¬ 
tion classes). The new EWIR database retains only the RF ECCM class as one of the 
inheritance specializations (See Figure 18). This single specialization adequately repre¬ 
sents the purpose and structure of WARM in the new EWIR object-oriented specification. 
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6. The EWIR Parametric Data 

The parametric data classes in the new EWIR database are essentially repositories 
of logically related EW parametric data. The parametric data classes in this thesis are pri¬ 
marily part of 1:1 relationships with the specialization classes of the major subsections. 
With only the specialization-to-generalization path available in the Object-Oriented Inter¬ 
face, all of the classes are reachable. The parametric data specification in the new EWIR 
database is shown in Figure 19. 
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IV. THE IMPLEMENTATION OF THE EWIR DATABASE 


In Chapter III the object-oriented specification of the existing EWIR database is 
reduced to an implementable size. The next step is to translate the new EWIR specifica¬ 
tion in Chapter IE into a database schema usable by the Object-Oriented Interface. The 
database schema is constructed using the O-ODDL as specified and referenced in Chapter 
II. In Section A of this chapter, the schema of the new EWIR database is presented. The 
files created by the Object-Oriented Interface which are derived from the schema are the 
Data Dictionary, the Descriptor File, and the Template File. These files are also described 
in Section A. 

Once the Object-Oriented Interface has accepted the database schema and created 
the requisite files, it is ready to accept the record data. In Section B, the process of insert¬ 
ing the EWIR record data into the newly created EWIR database is discussed. This section 
also includes the record format used by the mass load function of the Object-Oriented 
Interface. With the loading of the EWIR data into the new EWIR database, the process of 
creating a live EWIR database is complete. The database is now ready to execute transac¬ 
tions. 

A. THE DATA DEFINITION OF THE EWIR DATABASE 

Using the new EWIR database specification developed in Chapter El, the object 
classes to be implemented are easily identified. The Object-Oriented Interface requires 
strict formatting for the schema definition. In the object-oriented specification of the exist¬ 
ing EWIR database [Ref. 1], no formatting restrictions were applied to class and attribute 
specifications because the specification was not tied specifically to the Object-Oriented 
Interface. In conforming to the Object-Oriented Interface standards, the following restric¬ 
tions are applied when translating classes and attributes from the object-oriented specifica¬ 
tion to the database schema: 

• Class names are limited to seven characters. 

• Attribute names are limited to fifteen characters. 
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• No class names or attribute names can be identical. 

• All inherited classes must be specified before the class that inherits. 

• The second character of attribute name is not an underscore. This restriction is 
evident only when mass loading the record file onto the backend system. The 
DDL compiler of the Object-Oriented Interface will allow the underscore. The 
source or reason for this restriction during the mass load is unknown. 

The restriction of class names to seven characters creates two problems. The first 
problem is not being able to have semantically meaningful class names. In a large, com¬ 
plex database such as EWIR, a seven-character limit is inadequate for users to easily asso¬ 
ciate class names with their purpose. A second problem is correlating a class name in the 
new EWIR database schema with the class name used in the EWIR specification in Chap¬ 
ter III. To facilitate translation. Figure 20 is a listing of identical classes in the EWIR 
schema and the EWIR specification. 


Specification 

Schema 


Specification 

Schema 

Elnot 

Elnot 


Data_admin_info 

Data ds 

Comment 

Comment 


Numeric_data 

Num dat 

Specific_value 

Spec va 


Value_range 

Val ran 

Transmission_power 

Transj) 


Constant_power 

Constj) 

Not_constant_power 

N con _p 


Signal 

Signal 

Textual_data 

Text da 


Rf_line_structure 

Rf 1 St 

Pulsed_rf 

Pulsed 


Rf_not_constant 

Rf n CO 

Pulsed_rf_agility 

Puljf 


Discrete_agility 

Discag 

Warm 

Warm 


Rf_eccm 

Rf_eccm 

Polarization 

Polariz 


Circ_or_ellip_polariz 

Cel_po 

Scan 

Scan 


Mechanical_scan 

Mechsc 

Track 

Track 


Mechanical_tracking 

Mechjr 

Sector 

Sector 


Radiation_pattem 

Rad_pat 

Directional 

Directi 


Antenna 

Antenna 

Doppler_processing 

Doperjp 


Signal_processing 

Sigj>ce 

A_d_converter 

A_d_con 


Receive 

Receiver 

Emitter 

Emitter 





Figure 20. The Conversions of EWIR Specifications to Schema Class Names. 
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To this point, the only class attributes depicted are those which are themselves 
classes connected via a 1:1 relationship. For example, an attribute of Antenna is antjiirec 
(of type Directi) which is another class. In the EWIR schema, a listing of all attributes of 
each class is included. The attributes in the new EWIR schema do not include all of the 
class attributes delineated in the object-oriented specification of the existing E’WIR data¬ 
base [Ref. 1]. The attributes of the new EWIR schema are those which best capture the 
function of the class. This allows the new EWIR database to retain the essential function¬ 
ality and characteristics of the existing EWIR yet be of implementable size for the Object- 
Oriented Interface. 

1. The Schema Listing 

In Figure 21(a) and 21(b) is a listing of the new EWIR schema file (filename: 
EWTROODL). In Chapter II, Figures 3 through 6 explain the DDL constructs used in the 
class specifications on the Object-Oriented Interface: 

2. The Data Dictionary 

The Object-Oriented Interface accepts the new EWIR schema and creates a data 
dictionary (filename: EWIROODB.dict). A data dictionary describes the database struc¬ 
ture, information, and physical database design such as storage structures, access paths 
and record sizes. The data dictionary in the Object-Oriented Interface is referenced by the 
query constructor when performing data manipulation functions. 

The data dictionary generated by the Object-Oriented Interface for the EWIR data¬ 
base is listed in Appendix B. In Figure 22, a description of the data dictionary constructs 
used in the Object-Oriented Interface is given. Detailed information on the Object-Ori¬ 
ented Interface Data Dictionary can be found in Ref. 5. 

3. The Template File 

The Object-Oriented Interface also creates a template file (filename: 
EWIROODB.t). The purpose of the template file is to provide the specification of the 
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class Elnot{ 


}; 


class Spec_va: inherit Num_(lat{ 
char_string value; 

}; 


}; 


class N_con_p: inherit Trans_p{ 


char_string 
Emitter ^ 

elmt_notation; 

emit_system; 


j Spec va 

f ' 

max_change; 

class Data_ds{ 
char_string 
char^string 

ctrib_agency; 

last_update; 


/ class Signal! 

/ Const_p 

1 N con p 

scon_pwr; 

sn_con_pwr. 

class Comment! 
char string 

}; 

comt_data; 


I class Text_da! 

char_string 

1 Comment 

Data_ds 

text_dpt; 

text_com; 

text_dsp; 

class Num_dat{ 
char_string 
Comment 
Data_ds 

units; 

num_com; 

num_dsp; 

Flo 

i; }> 

class Rf_l_st! 
Spec_va 
Text_da 

1 . 

db3_s_width; 

txmitter_type: 


class Pulsed: inherit Signal{ 
Rf_l_st coherence: 


class Rf_n_co: inherit Pulsed{ 


char_string 

lwr_value; 

1 char_string 

dummy; 

char_string 

upr_value; I 

}; 




class Pul_rf: 

inherit Rf_n_co{ 

class Trans_p{ 

1 

Text_da 

agt_f_correl; 

Spec_va 

txjs_tx; / 

}; 


Val_ran 

Spec va 
l* 

pk_pw_rad; / 

pk_pw_txmittei / 

class Disc_ag 

: inherit Pul_rf{ 

Text_da 

mod_waveform; 

/ ? 

/ 

Val^ran 

rf_limits; 

class Const j): 

: inherit Trans_p y 

Spec_va 

no_disc_steps; 

Spec_va 

tto_switch; 




Figure 21(a). The EWIR Schema Specification. 
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class Warm { 

char_string prob_code: 


class Rf_eccm : inherit Warm { 
set_of Disc_ag rf_disc_agility; 

}; 

class Polariz{ 

char_string polar_data; 

}: 

class C_el_po: inherit Polariz{ 
Text_da sense; 

Spec_va ax_ratio; 


class Scan{ 

Spec_va smp_avg_time; 

Spec_va threshold_meas; 

Text_da plane_scan; 

}; Flow 

class Mech_sc : inherit Scan{ 

Text_da stp_cg_ahility; 

Text_da sc_function; 


class Track{ 

Text_da plane_track; 

}; 

class Mech_tr; inherit Track! 
Val_ran niax_r_a 

Val_ran max_r_e 

}; 

class Sector: inherit Me( 
Text_da sec_l^; 
Val_ran per_limits; 

Spec_va sec_w_az: 

Spec_va sec_w_el; 

Mech_tr sm_track; 

}; 

class Rad_pat{ 

Spec_va ant_gain; 


class Directi: inherit Rad_pat{ 

Spec_va bwdth_az; 

Spec_va bwdth_el; 

Spec_va first_az; 

Spec_va first_el; 

Sector sec_char, 

}; 

class Antenna! 

Text_da ant_type; 

Text_da ant_function; 

Spec_va hor_dimension; 

Spec_va vert_dimension; 

C_el_po ac_el_pol; 

Directi ant_direc; 

inverse_of Emitter.ant_comp anten_emit; 

}; 

class Doper_p{ 

Spec_va coh_pcess_int; 

Spec_va num_pulses_cpi; 

1; 

class Si g p ee! 

Doper_p doppler_calc; 

} > 

class A_d_con{ 

Spec_va ad_samp_period; 

Text_da conv_trig_metho; 

}; 

class Receive! 

Text_da receiver_type; 

Sig pee sig_processor; 

A_d_con ad_section; 

}; 

class Emitter! 

Elnot uniquejd; 

Rf_eccm erf_eccm; 

set_of Receive recjcomp; 
set_of Antenna ant_comp; 
set_of Const_p econ_pwr; 
set_of N_con_p en_conjpwr; 
set_of Disc_ag edis_agility; 

Text_da weap_system; 

Text_da emit_function; 

Text_da emit_ptf_gen; 


Figure 21(b). The EWIR Schema Specification. 
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EWIROODB 

@ ◄ - 

Elnot - 

# ◄ - 

OID ^ - 

s ◄- 


Name of the database 

Marks the beginning of a new class 

Class name 

Separates attribute fields within the class 
System generated OID attribute field 
Type of attribute field (s = character string) 


# 

ELINT_NOTATION 
s 


# 

EMIT_SYSTEM 

s 

emitter ^ 
ref 




Attribute name 


Attribute EMU SYSTEM is of type (class) emitter 


Figure 22. The Data Dictionary Format. 


object-oriented EWIR database in an equivalent kernel database. The template creates the 
attribute-value pair used by the kernel system. In Appendix C, a complete listing of the 
new EWIR database template file is provided. The format of the template file used in the 
Object-Oriented Interface is provided in Figure 23. For more information on the Object- 
Oriented Interface template file, see Ref. 6. 

4. The Descriptor File 

The Object-Oriented Interface creates an EWIR descriptor file (filename; 
EWIROODB.d). The descriptor file is used by the Language Interface Controller for com¬ 
munication with the kernel system. The descriptor file provides the kernel system a listing 
of all database classes including those not specified by the user. For example, the set_of 
relationship in the database schema results in a new class generated by the Object-Ori¬ 
ented Interface. Specifically, the class Emitter has an attribute of type set_of receivers. In 
Figure 24, the new system generated class Receiver_emitter is listed. Receiver_emitter 


36 





was not a user-defined class in the EWIR schema. The entire EWIR descriptor file is listed 
in Figure 24. See Ref. 5 for more information on the Object-Oriented Interface descriptor 
file. 


EWIROODB 
4 - 


Elnot -- 

TEMP s - 

OID s - 

ELINT_NOTATION s 
EMIT.SYSTEM s 
4 

Data_ds 
TEMP s 
OID s 

CTRIB_AGENCY s 
LAST_UPDATE s, 

3 


Name of the database 
Number of classes in the entire database 
Number of attribute fields of the next class 
Name of the class 

First attribute (always a temp) and type (s) 
OID attribute 

User Defined Attributes and type (s). 
type s is a character string. 


Comment 
TEMP s 
OID s 

COMT_DATA s 
5 

Num_dat 
TEMP s 
OID s 
UNITS s 
NUM.COM s 
NUM_DSP s 
4 



yalue 


ttribute. 


.attribute-value pair 


Spec_va 
TBMP s 
OIDs 

OID_NUM_DAT s 
VALUES 


Figure 23. The EWIR Template File Format. 
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EWIROODB ◄- 
TEMPbs 

! Elnot - 

! Data_ds 
! Comment 
! Num_dat 
! Spec_va 
! Val_ran 
! Trans_p 
! Const_p 
! N_con_p 
! Signal 
! Text_da 
! Rf_l_st 
! Pulsed 
! Rf_n_co 
! PuLrf 
! Disc_ag 
! Warm 
! Rf_eccm 
! Disc_ag_rf_eccm 
! Polariz 
! C_el_po 
! Scan 
! Mech_sc 
! Track 
! Mech_tr 
! Sector 
! Rad_pat 
! Direct! 

! Antenna 
! Doper_p 
! Sig pee 
! A_d_con 
! Receive 
! Emitter 

! Receive_emitter 
! Antenna_emitter 
! Const_p_einitter 
! N_con_p_emitter 
! Disc_ag_emitter 


Name of the database 


Listing of all classes in the database 


System-generated classes from set_of 
relationships defined in the schema 


Figure 24. The EWIR Descriptor File. 




B. THE EWIR DATABASE RECORD DATA 

The Insert function of the Object-Oriented Interface has not been implemented, 
and thus a record-by-record insertion of data is not available. Instead, the mass load func¬ 
tion is used to load all record data. The EWIR record file (filename: EWIROODB.r) is cre¬ 
ated by the user to mass load all of the EWIR record data into the EWIR database. When 
using the mass load option, the user must adhere to the following conventions when spec¬ 
ifying the record data: 

• Classes occur in the same order as the schema file (EWIROODL). 

• Attributes are in the same order as listed in the schema. 

• The @ symbol is used to separate classes. 

• The user generates the ODD’s. 

• If a class inherits from another class, then the OID format of the generalization 
class is used by the specialization class followed by “na”. Thus a specialization 
class record would have the following format: 

< OID of generalization> na attribute! attribute2.attributeN 

• An illustration of how to translate the schema specification into the record data 
format is illustrated in Figure 25: 


Schema file 


Record file 

@ 

class Num_dat{ 


Num_dat 

char_string 

units; —s. 

30 deg CMl DDl 

Comment 

nuin_com;^ 

/ \ vv 

Data ds ^ 

num__dsp; \ 

, / 1 


1 

1 unique OID \ \\ 

- data value for units 

=&■—^ Comment and Datajis OID *s 


Figure 25. The Record File Format. 


39 









1. A Proposed EWIR Record Template 

When entering data into a database, the database user typically has an interface 
designed to collect related record information. The database interface can be of many dif¬ 
ferent types. User-friendly interfaces may include a menu-based interface, a graphical 
interface, or a forms-based interface. A logical choice for inserting, data into the EWIR 
database is a forms-based interface. A forms-based interface allows the user to insert data 
into an Emitter template form which collects logically related information and then inserts 
the data into the database. 

A sample forms-based interface for the new EWIR database is provided in Figure 
26. The user-provided EWIR data is in italics. This sample database insertion form is very 
large and packed with information about a single emitter. The nature of the EWIR data¬ 
base is such that large amounts of information is logically related to a single emitter. 
Because the mass load function is the only available method for insertion of data, this 
sample template is not actually used in this implementation. It is presented in this thesis to 
illustrate the complexity of a single object “emitter”. The template also provides a logical 
collection of emitter data for testing the accuracy of transactions on the sample emitter. 
When the Object-Oriented Interface implementation is expanded to include the insert 
function, a well designed and user-friendly interface can be developed. 

2. The Mass Load Record File (EWIROODB.r) 

In a commercial database system, the user will never be concerned with the physi¬ 
cal storage structures of the database. The insert function will handle the data storage 
details. For the purposes of this thesis, it is important to show the EWIR record data used 
by the mass load function because it must be created by the user. The EWIR mass load 
record is listed in Figure 27(a) and 27(b). The logically related record of Figure 26 is inte¬ 
grated into the mass load record file as well as generic test data. Please note that all record 
data names (i.e.,names of radars) and values (parameters) are not actual real-world 
EWIR database names and values. Creating and testing the EWIR database on the Object- 
Oriented Interface is an unclassified research project and thus precludes the use of real 
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EWIR data. The mass loading of the EWIROODB file completes the creation of the new 
EWIR database. 



RECEIVERfRECl) 

Receiver_type: pulse wave 
Signal processor: 
doppler calc: 

coh_pcess_int: 300Jew 
num_pulses_cpi: 20_cpi 
A_D section: 

ad_sample_period: 325jns 
conv_trig_method: sinjwave 

SIGNAL DATAfSIGS) 

mod_wa.vefoxm:pulse_wav 

rf_limits:728_/iz 

no_disc_steps:i2 

EM CON PWR(TPl) 

trans_loss_on_tx:5_rf& 
pk_pwr_rad: 300Jew 
pk_pwr_tx: 300Jew 


Emitter: Sample_l 
Unique_id: 

elint_notation:e/rtor_i 
Probability code: probj 
Receiver components:RECl 
Antenna component: A1 
Econ_pwr: TPl 
non_constant_pwr: TP3 
Discrete_agility: SIG5 
Weapon systemAA-d 
comvt\&at:satellite_detect 
contributing agency: Airforce 
last update: 08-95 
Emitter function: bng_range_aa 
comment: aircraftjnounted 
contributing agency: Airforce 
last update: 08-95 
Emitter_ptf_gen: mod_pulse_wave 

ANT COMPONENTl (All 
antenna_type: parabolic 
antenna_function: long_range_aa 
horizontal_dim: 3 Jt 
vertical_dim: 4 Jt 
circ_or_ellip polarization: 
sense: left 
ax_ratio: 20_db 
antenna_direction: 
bwdth_azim: one_way_3db 
bwdth_elev: 6 deg 
first_az: 12_db 
first_el: 15_deg 
Sector: 

sector_type: unidirct 
per_limits: 6_sec 
spc_vf_az:6_sec 
sec_w_el: 6_sec 
Mechanical_track: 
plane_track:45_/ior 
max_r_az: 20_db 
max r el: 5 db 


Figure 26. A Sample EWIR Record Template. 
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HWlKUUUtS 

@ 

Name of database 

cinot - 

El e_notl EMI __ 

Class name 

E2 e_notl EM2 ^ - 

E3 e_notl EM3 ^ 

three records in class 

a new class 

DDl airforce 08_95 

“contributing agency” attribute 

uuz auTorcc uo yj 

@ 

Comment 

CM2 satellite_det ^ 

" "" lasl update attribute 

CM3 aircraft mount 


@ 

Num dat^^ i 

N1 30 deg CM3 DDl / 
N2 45_deg CM3 DD2y 
N3 unit3 CM3 DD2 

N4 unit4 CM2 DDl 

N5 units CM2 DD2 

N6 unite CM2 DD2 
@ 

attribute is of type data ds 

Spec_va is a specialization ofNum_dat 
as signified by the “na” and OID ofNl 

Spec_va^^^,*.— 

N1 naTzSlms 

N2 na 300_kw 



Figure 27(a). The EWIR Record File. 
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(continued from Figure 27(a)) 


N3na4_ft 

@ 

N4na3 ft 

^ Rf 1 St 

N5na20 db 

^ RFLINITEI 

N6 na 5_db 

/ RFL2N2TE2 

N7 na 20 cpi 

/ @ 

N8 na10_db 

/ Pulsed 

@ 

/ SIGlnaRFLl 

Val_ran 

/ SIG2 na RFL2 

N4 na 100_ins 128_ms 

/ @ 

N5 na lower_val2 upper_val2 

/ Rf_n_co 

N6 na lower val3 128 hz 

/ SIGlnadummyl 

@ 

/ @ 

Trans p 

/ Pul rf 

TPl N1N4N2 

1 SIGl na TEl 

TP2N2N5N1 

1 SIG2naTE2 

TP3N3N6N2 

SIG3naTE3 

TP4N1N6N3 

@ 

TP5N6N6N3 

1 Disc ag 

@ 

SIGlnaTE5N4Nl 

Const p 

SIG2naTE2N5N2 

TPlnaN2 

SIG3naTE3N6N3 

TP2naN3 

SIG5naTE3N3N6 

@ 

@ 

N con_j) 

Warm 

TP3naN3 

W1 probl 

TP4 na N1 

W2 prob2 

@ flo 

y @ 

Signal 

Rf_eccm 

SIGl TPl TP3 

I W1 na 

SIG2 TP2 TP4 1 

@ 

SIG3 TP3 TP4 

1 Disc ag rf eccm 

SIG4TP2TP3 

DCAl SIGl W1 

SIG5 TP5 TP3 1 

DCA2 SIG2 W2 

@ 

@ 

Text_da 1 

Polariz 

TEl phased_array CMl DDl / 

PI pdatal 

TE2 parabolic CM2 DD2 / 

P2pdata2 

TE3 mod_pulse_wave CMl DD3 / 

@ 

TE4 lng_rang_aa CM2 DDl / 

C el po 

TE5 pulse wave CMl DD2 / 

PlnaTE6N5 

TE6 left CMl DD2 / 

P2naTE2N2 

TE7 45_horCM2DD2 / 

P3naTE2N5 

TE8 square sail CM2 DDl / 

P4naTE6N5 

TE9 aa 10 CM2 DDl / 

@ 

TEIO aa 6 CM2 DD2 / 

Scan 

TEll sa_21 CM2 DD2 / 

SCAl N1 N3 TEl 

TE12 unidiict CM2 DD2-/ 

SCA2N2N1TE2 


SCA3N3N2TE3 


Figure 27 (b). The EWIR Record Data. 
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Figure 27(c). The EWIR Record Data. 
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V. THE MANIPULATION OF EWIR DATA 


In Chapter III of this thesis, we derived the new EWIR database from the object- 
oriented specification of the existing EWIR database. In Chapter IV, the new EWIR data¬ 
base was transformed from an O-ODM specification into a live database using the DDL of 
the Object-Oriented Interface. In Section A of this chapter, we state the objectives and 
goals achieved through the execution of transactions on the live EWIR database. In Sec¬ 
tion B, we present the nine transactions on the live EWIR database using the DML of the 
Object-Oriented Interface. 


A. THE GOALS OF THE EWIR TRANSACTIONS 

The transactions or queries on the EWIR database are the final step required to 
reach our thesis goals and objectives. They provide a basis for evaluating the effectiveness 
of the Object-Oriented Interface as well as the merits of an object-oriented implementa¬ 
tion of the EWIR database. The transactions or queries utilize and test the implemented 
functions of the Object-Oriented Interface while capturing the EWIR database functional¬ 
ity. In particular, the transactions are intended for the following: 

• To test every type of relationship in the database. These relationships include 
inheritance, 1:1, 1:N and M:N. 

• To span the most complex data relationships encountered in the live EWIR data¬ 
base. These include the multiple-level inheritance and multiple-level 1:1 rela¬ 
tionships. 

• To utilize all available DML operations currently implemented on the Object- 
Oriented Interface. These operations include Obj_set, Object_refs, Find_one, 
Find many. Display, Contains, And, Or, and the looping structure (For Each 
<obj_r^> In <obj_set>). 

• To access and manipulate data from disparate sections of the database. In other 
words, the information from the antenna, signal, and receiver sections can be 
accessed and manipulated in a single query. 

B. THE EWIR TRANSACTIONS 

The queries presented in this section are representative of the type of ad-hoc trans- 
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actions an analyst might submit to the EWIR database. These queries are designed for 
testing the database and do not reflect any strategic relevance. It is also important to note 
once again that the data values and names used in the new EWIR database are not the 
actual values and names of “real world” parametric data, thereby keeping the research 
project unclassified. 

Nine queries are presented in this thesis. A standard format is used for presenting 
all the nine queries. The query presentation format is explained in Figure 28. The compiler 
output is useful for debugging the queries and for following the sequence of execution of 
each query [Ref. 6]. 

#. < Subsection Title > 

Purpose: The research purpose of the query. 

Request: The transaction to be performed stated in English. 

Query: The query in the DML of the Object-Oriented Interface. 

Result: The values returned by the query. 

Remarks: Any remark or figure as required. 

Figure 28. The Query Presentation Template. 

The limitations experienced in writing the queries are mainly a function of the lim¬ 
itations of the Object-Oriented Interface. The specialization-to-generalization path for an 
inheritance limits the scope of retrievable information. The lack of an if-then-else state¬ 
ment limits the complexity and sophistication of the queries. Given the functions currently 
available, the following nine queries evaluate the current data manipulation capabilities of 
the Object-Oriented Interface. These queries also provide enough context to evaluate the 
effectiveness of an object-oriented approach to manipulation of EWIR data. 
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1. An Attribute Look-up (Query_1) 

Purpose: The primary purpose of Query_l is to explain the mechanics of how the Object- 
Oriented Interface processes a query using only the schema and record files. An illustra¬ 
tion of the Query_l execution logic is provided in Figure 29. Query_l is a simple attribute 
look-up involving a 1:1 relationship. 

Request: Find an antenna with the long-range, anti-air capability. 

Query: 

Query Find_antenna IS 
obj_ref p; 

Begin 

p:= find_one Antenna where ant_function.text_dpt = ‘lng_rang_AA’; 
display(p.ant_type.text_dpt); 

End; 

Result: Text_dpt: phased array 

Remarks: When hand-tracing the execution of an EWIR query, we use the schema file 
and the record file. Refer to Figure 29 when reading the following explanation. 

We start with the assignment statement in the body of Query_l. It assigns to the 
variable p the ODD of the Antenna whose function is long-range-anti-air (lng_rang_aa). 
Thus, by first looking at the schema, the ant Junction attribute is observed to be of type 
Textjda. therefore, we now locate the class Text_da and, following the dot notation, locate 
the attribute text_dpt. The text dpt attribute is the first attribute of class Text da. Using 
this information, we now move to the record file and locate the class Textjda. The inspec¬ 
tion of class Text da records tenrunate when we locate the value “lng_rang_aa” in its first 
attribute field. A match is made with the record having an ODD of TE4. 

The OID value of TE4 is required as a second attribute in a record of class 
Antenna. Thus, the Antenna records in the record file are searched until TE4 is found in 
the second attribute field. The match is made with the Antenna having an OID value of 
Al. The Antenna OID value of A1 is now assigned to the variable p. 

The display statement now uses the antenna with the OID of A1 to output the 
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requested information. Note that the display statement in this query also involves dot nota¬ 
tion: 

display (p.ant_type.text_dpt); 

The p.antjype is the first attribute of Antenna. For the antenna with an ODD of Al, the 
antjype attribute is TEl. The record with the ODD of TEl is located. The textjdpt 
attribute is the first attribute field in the record. The textjlpt attribute of TEl has the value 
phased_array. Thus, phased_array is the output of the query. 



2. A Single-level Inheritance and its 1:1 Relationship (Query_2) 

Purpose: The purpose of Query_2 is to complete a one-level 1:1, one-level inheritance 
transaction. Also, new to this query are multiple outputs in a single display statement. The 
display statement is recoded to handle multiple outputs in a single statement. The previous 
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version allowed only one output per display statement. The display statement in Query_2 
uses the three-level dot notation for its output. A graphic representation of Query_2 is pre¬ 
sented in Figure 30. 

Request: Find the antenna t)q)e, antenna function, contributing agency and last update of 
an antenna with cross polarization. 

Query: 

Query Cross_polorization IS 
obj_ref p; 

Begin 

p:= find_one antenna where ac_el_pol.polar_data = ‘cross_polarize’; 
Display (p.ant_type.text_dpt, p.ant_function.text_dpt, 

p.ant_type.text_dsp.ctrib_agency,p.ant_type.text_dsp.last_update) 

End; 

Result: ant_type: phased array 

ant_function: lng_rang_aa 
ctrib_agency: airforce 
last_update: 08 - 95 

Remarks: The inheritance hierarchy makes the attributes of the inherited classes to 
appear as if they are part of the inheriting class. This negates the requirement for path 
statements using dot notation to access multi-level inherited data. It greatly simplifies the 
query while providing powerful data manipulation functionality. 

In Figure 30 is a depiction of Query_2. Notice the depiction of polar_data as an 
attribute of Circ_or_Ellip_Polarization by virtue of an inheritance. All of the inherited 
class attributes become “virtual” attributes of the class which inherits. 

3. Multi-Level 1:1 Relationships (Query 3) 

Purpose: The most complex relationship in the Antenna Data section involves four levels 
of 1:1 relationships plus a one-level inheritance. This query requests information that fol¬ 
lows the four-level path statement plus a single-level inheritance. Also presented in 
query_3 is the logical operator Or. It is used for an alternative decision path involving a 
three-level 1:1. Query_3 also introduces the findjnany statement resulting in multiple 
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The path statement (from query_2)’is 
ac_el_pol.polar_data. The polar_data 
attribute is actually an attribute of class 
Polarization, yet through inheritance the 
path statement makes polar_data appear 
to be an attribute of ac el j)ol. 


Figure 30. The Logic of Query_2. 


object retrievals in a single statement The output of these multiple objects is achieved 
using the looping structure For each <var> in <var>. 

Request: Find the antennas with a tracking plane of 45 degrees horizontal OR a sector 
scan that is unidirectional. 

Query: 

Query track_plane IS 

obj_ref i; 
obj_set p; 

Begin 

p:= find_many antenna where 
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ant_direc.sec_char.sm_track.plane_track.text_dpt = ‘45_hor’ 

OR ant_direc.sec_char.sec_type.text_dpt = ‘unidirct’; 

For each i IN p 
display(i.ant_type.text_dpt); 

End_loop; 

End; 

Result: Text_dpt: phased_array 
parabolic 
sqmre_sail 

Remarks: A graphical depiction of the query is presented in Figure 31. Unlike the inherit¬ 
ance hierarchy, the multiple-level 1:1 structure must be explicitly expressed via a path 
statement using the dot notation. The statement “p:= find_many antenna” indicates that 
the class Antenna is the starting point in the path. The statement “where 
ant_direc.sec_char.sm_track.plane_track.text_dpt” is a listing of the attributes to follow to 
find the data value ‘45_hor’. 

The 1:1 relationship is useful because it allows a class (or object) to be composed 
of other classes. This enables high levels of abstraction for the user. For example, a car is a 
collection of objects (engine, body, seats, etc.). These objects are in turn composed of 
other objects (engine => block, cylinders, fuel system, etc.). The division of a car into 
smaller subcomponents continues until it reaches the indivisible (atomic) parts. Thus, it is 
easier to understand a car as a small collection of major subcomponents (engine, body, 
etc.) than a huge collection of thousands of small parts (plugs, bolts, fabric, rubber, etc.). 
An atomic-level component can be identified by successively identifying smaller and 
smaller subcomponents along a logical path until it reaches the desired atomic-level com¬ 
ponent. 

An example of a path statement using the car example is the following: To find the 
car with a spark plug gap of 0.05 inches. Starting at the Class Car, the example can then 
traverse the following path: 

Find one Car where engine.elect_system.ignition_system.spark_plug.gap = ‘.05’ 
This path follows a series of specialization attribute classes until it reaches the target class 
and the attribute of interest. This logic is employed by the Object-Oriented Interface when 
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executing multi-level 1:1 relationships. A depiction of the multi-level 1:1 relationship of 
query_3 is illustrated in Figure 31. 
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* Both of the paths lead to retrieval of an OID from the Text da class. The 
OID is then matched with the OID in the text_da attribute location in the 
antenna records. Ultimately, the Antenna OID’s are retrieved which contain 
the correct Text da OID attribute. 


Figure 31. The Multi-level 1:1 Relationship of Query_3. 


4. A Two-level Inheritance (Query_4) 

Purpose: The purpose of Query_4 is to illustrate a two-level inheritance. Thus far we 
have done a simple attribute look-up (query_l), a one-level inheritance and 1:1 relation¬ 
ship combination (query_2), a multi-level 1:1 (query_3). The multi-level inheritance of 
this query completes the testing of basic EWIR data relationships on the Object-Oriented 
Interface. 

Request: What are the sector type and the upper and lower values of the period limits of 
an antenna with a sample average scan time of 325 ms? 

Query: Query Find_sector IS 


52 









Begin 

p:= find_one sector where 
smp_avg_time. value = ‘325_ms’; 
display(p.sec_type.text_dpt,p.per_limits.lwr_value, 
p.per_limits.upr_value); 

End; 

Results: Text_dpt: unidirect 

Lower_value: lOOjns 
Upr_value; 128 jns 

Remarks: The relative simplicity of queries involved in inheritance hierarchies is a major 
strength of object-oriented database systems in general and the Object-Oriented Interface 
in particular. For example, the attribute smp_avgjime is not an attribute of sector, but sec¬ 
tor inherits from Mech_sc. The smpjtvgjime attribute is not located in Mech sc, but 
Mech_sc inherits from Scan. The attribute is located in Scan where a match is made. The 
inheritance structure does not require the use of any dot notation, thus greatly simplifying 
the structure of the query. The query_4 logic is illustrated and explained in Figure 32. 


p:= find_one sector where 
smp_avg_time. value = ‘325_ms’; 


check sector 
attributes 


smp_av_time is an attribute 
of Scan. The match with 
value ‘325_ms’ is made and the 
ODD is returned. 

C Scan j t 


Csector 




smp_av_time is 
not an attribute 
of Sector. Check 
Mechanical Scan 


y -^ 

Mechanical scan 




inherited 

class 


smp_av_time is not 

inherited class an attribute of Mechanical 

Scan. Check Scan. 


Figure 32. The Two-Level Inheritance of Query 4. 
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5. A Five-level Inheritance and One-level 1:1 Relationship (Query_5) 

Purpose: The purpose of query_5 is the data retrieval from Signal Data via the most com¬ 
plex structure available. The complexity is defined in terms of depth of data relationships. 
This particular query will traverse through five levels of inheritance plus a 1:1 relationship 
in total. This is the deepest inheritance structure in the entire live EWIR database. Notice 
that despite the complexity of the query in terms of the depth, the query stracture itself is 
very simple. 

Request: What are all modified waveforms (discrete agility) of a signal that is transmitted 
at a constant peak power of 300 kw? 

Query: 

Query Find_waveforms IS 
obj_set p; 
obj_ref i; 

Begin 

p:= find_many disc_ag where 
scon_pwr.pk_pw_txmitter.value = ‘300_kw’; 

For Each i IN p 

display(p.mod_waveform.text_dpt); 

End_loop; 

End; 

Result: Text_dpt: pulsejvave 

mod_pulse_wave 

Remarks: In Figure 33 is a graphical depiction of the path taken through the five levels of 
inheritance and the 1:1 relationship. The mechanics of inheritance relationships is 
explained in both Query_2 and Query_4. Query_5 is the initial test of a change to the 
Object-Oriented Interface code allowing four-levels of an inheritance in a single query. 
The previous code restricted the inheritance hierarchy to three-levels. 
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Figure 33. The Multi-level Inheritance Hierarchy of Query_5. 


6. The Retrieval of the Emitter ELNOT (Query_6) 

Purpose: The ELNOT is the notation used to uniquely identify the emitter in the EWIR 
database. It is essential to be able to provide ELNOT information to the user, given an 
emitter’s parametric data. When given parametric data, the query_ 6 retrieves the associ¬ 
ated emitter ELNOT. 
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In Query_6 we use the contains statement for the first time. The contains statement 
is a set comparison function. It returns the objects in a set which satisfy an expression or 
match objects in a second set. 

Request: What is the ELNOT and the weapon system for an emitter with an antenna hav¬ 
ing a mechanical scan tracking plane of “45_hor”? 

Query: 

Query find_emitter IS 

obj_ref p,i; 
obj_set q 
Begin; 

p:= find_one antenna where 

ant_direc.sec_char.sm_track.plane_track.text_dpt = ‘45_hor’; 
q:= find_many emitter where ant_comp contains p; 

For Each i IN q 

display(q.unique_id.elint_notation, q.weap_system.text_dpt); 

Endjoop; 

End; 

Results: Elint_notation: enot_l 
Text_dpt: aa_6 

Remarks: In Figure 34 is a depiction of the Query_6 logic. The EWIR schema file shows 
that the class Emitter uses the set_of construct for the antenna_component (ant_comp) 
attribute. The meaning of set_ofis that one emitter can have many antennas. In this query, 
all of the antennas of an emitter are searched, using the contains statement, for a match 
with the data contained in the variable p. The results are stored in the variable q for even¬ 
tual display. 

7. The Retrieval of Parametric Data Given an ELNOT (Query_7) 

Purpose: The purpose of query_7 is to retrieve the parametric data of an emitter given 
only its ELNOT. The ELNOT is the highest-level identification of an emitter and can 
therefore be used to retrieve any of the related emitter data. This is essentially a reverse 
operation of Query_6 which returned an emitter ELNOT given specific parametric data. 


56 




Request: Retrieve all weapon systems and the associated antenna type for a given an 

emitter ELNOT of enotl. 

Query: Query find_emitters IS 

obj_ref i; 
obj_set p, q; 
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Begin 

p:= find_many emitter where 

unique_id.elint_notation = ‘e_notr; 
q:= find_many antenna where anten_emit contains p; 

For Each i IN p 

display(i.weap_system.text_dpt); 

End_loop; 

For Each i IN q 
display(i.ant_type.text_dpt); 

End_Ioop; 

End; 

Results: Text_dpt: su_22 
mig_21 
mig_23 

Text_dpt: phased_array 
sqmresail 

Remarks: A visual depiction of Query_7 is illustrated in Figure 35. 



Figure 35. The Retrieval of Parametric Data for a given an ELNOT. 
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8. Multiple Logical Operators and Changing Data (Query_8) 

Purpose: The primary purpose of query_8 is to retrieve data using multiple logical opera¬ 
tors, change the value of an attribute, and store the new value in the database. Thus, 
Query_8 only replaces the attribute value of an existing EWIR attribute and no modifica¬ 
tion in the schema takes place. 

Request: Downgrade the pulse wave radar from a long-range-aa to a medium-range-aa 

platform if the antenna type is phased array and its axial ratio value is ‘20_db’. 

Query: Query Change_antenna IS 

obj_ref p; 

Begin 

p:= find_one Antenna Where ant_function.text_dpt = Tng_rang_aa’ 
AND ant_type.text_dpt = ‘pulse_wave’ 

AND ac_el_pol.ax_ratio. value = ‘20_db’; 

Display (p.ant_type.text_dpt, p.ant_function.text_dpt); 
p.ant_function.text_dpt:= ‘medium_mg_aa’; 

Display (p.ant_type.text_dpt, p.ant_function.text_dpt); 

End; 

Results: Text_dpt: phased_array; lng_mg_aa; 

Text_dpt: phased_array; med_mg_aa 


Remarks: Figure 36 is the graphical depiction of query_8. 
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The antenna that meets all three criteria is assigned to the variable p. The 

antenna function (ant_function) is then changed via an assignment statement. 


Figure 36. The Changing of a Data Value (Query_8). 
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9. The Data Retrieval From Multiple Subsections of EWIR (Query_9) 
Purpose: The piupose of Query_9 is to retrieve data from all three major subsections of 
the EWIR database using the logical operators. Query_9 demonstrates that there are no 
limits to the number of major subsections of the EWIR database in performing a transac¬ 
tion. Without any higher level functions such as if-then-else, the complexity of the transac¬ 
tion is limited to logical comparisons of retrieved information. 

Request: Determine which weapon systems have a transmission loss on a transmit 
of 5_db or a receiver with doppler processing of 20_cpi or a directional radiation pattern 
antenna gain of 10_db. 

Query: 

Query multiple_choice IS 

obj_set q,z,y,p; 
obj_ref i; 

Begin 

q:= Find_many disc_ag where scon_pwr.tx_ls_tx. value = ‘5_db’; 
z:= find_many Receive Where 

sig_processor.doppler_calc.num_pulses_cpi.value =‘20_cpi’; 
y:= find_many antenna Where ant_direc.ant_gain.value = ‘10_db’; 
p:= find_many Emitter where edis_agility contains q OR 
rec_comp contains z OR 
ant_comp contains y; 

For Each i in p 

display(i.weap_system.text_dpt); 

Endjoop; 

End; 

Results: Text_dpt: aa_10 
aa_6 
sa_21 

Remarks: In Figure 37 is the graphical depiction of Query_9. The variables q, z, and y 
contain the OID’s of the qualifying objects from the Signal, Receiver, and Antenna sub¬ 
sections respectively. The variable p contains the OID’s of emitters whose attributes 
(edis_agility, rec_comp, ant_comp) contain the OID’s in q, z, and y. 
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scon_pwr.tx_ls_tx.value = ‘5_db’ 


sig_processor.doppler_calc.nuni_pulses_cpi.value = ‘20_cpi’ 


Discrete Agilit)J 



ant_direc.ant_gain.value = ‘10_db’ 



edis_agility/ cont^s q OR s'j:ec_( ;o'm>. OR 
\ cohtains z \ 


,aht_comp^contains y 


Emitter 


\ attribute ; 


p:= OID’s of the emitters which 
satisfy the logical statement. 


Figure 37. Data Retrieval From Different EWIR Subsections (Query_9). 
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VI. CONCLUSIONS 


In this thesis we first create a live EWIR database given only the object-oriented 
specification of the existing EWIR data. In Section A is a summary of the methodology 
used in this thesis to create the live EWIR database. We then create a number of live 
object-oriented transactions for the purpose of accessing and manipulating the newly cre¬ 
ated and live object-oriented EWIR database. In Section B is an evaluation of the perfor¬ 
mance of the Object-Oriented Interface in its support of our new and live transactions. In 
Section C, there is a conclusive discussion on the merits of the object-oriented implemen¬ 
tation of the EWIR database and its transactions. 

A. THE THESIS METHODOLOGY SUMMARY 

The Electronic Warfare Integrated Reprogramming (EWIR) database is the pri¬ 
mary Department of Defense source for technical parametric performance data on non¬ 
communications emitters. It has been identified by the National Air Intelligence Center as 
difficult to use in its current hierarchical database form. There are two problems addressed 
by this thesis. First, with object-oriented database management being the latest database 
technology, is an object-oriented EWIR database a superior method for managing com¬ 
plex electronic warfare data collections? Second, is the prototype Object-Oriented Inter¬ 
face of the Multimodel and Multilingual Database Management System developed at the 
Laboratory for Database System Research in the Naval Postgraduate School capable of 
supporting a complex object-oriented database such as EWIR and its transactions? 

To answer these questions, we first examine the object-oriented specification of the 
existing EWIR database [Ref. 1] and derive a subset for our implementation on the Object 
Oriented Interface. Using the Object-Oriented Interface DDL, the new object-oriented 

EWIR database schema and its associated data are stipulated and loaded into MODEMS in 
order to create the live database. Using the Object-Oriented Interface DML, nine object- 
oriented transactions for EWIR processing are elaborated and executed. The following 
sections summarize the results of this research. 
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B. THE EVALUATION OF THE OBJECT-ORIENTED INTERFACE 


The EWIR database is the first large, complex database implemented on the 

Object-Oriented Interface of the MODEMS. The EWIR implementation is designed to test 
the effectiveness, correctness, and efficiency of the Object-Oriented Interface. Specific 
conclusions on the Object-Oriented Interface include: 

• All functions currently implemented on the Object-Oriented Interface work as 
specified. Some minor code changes have been made during the course of this 
thesis to correct logic errors or expand the usability of the functions. 

• The inheritance relationship allows the data retrieval from a specialization class 
to a generalization class only. The inheritance functionality should be expanded 
to include data retrieval capability for the generalization class to specialization 
class direction. 

• The only functions which provide data manipulation capabilities are the 
find_one,find_many, contains, logical or, and logical and. These functions 
restrict transactions to object and object-set comparisons. Additional functions 
are needed to meet the extensive data manipulation requirements of large, real- 
world databases such as the full set of EWIR data. Recommended additional 
functions include insert, delete, and the if-then-else or case statement 

• In keeping with the object-oriented paradigm, it is recommended that future stu¬ 
dents implement methods. The methods provide to the user an external interface 
and also encapsulate the intended data operations for specific objects. The exter¬ 
nal interface is a key component of a complete object-oriented database system. 

• The character-length restriction on class names and attribute names should be 
eliminated. A large, complex database needs the versatility to clearly name 
objects. In this thesis, many class and attribute names are cryptic and difficult to 
understand due to this restriction. 

In summary, the Object-Oriented Interface forms an excellent foundation on which 
to create a complete object-oriented database system. The underlying kernel system is 
well designed and has a proven ability to support transactions from several different data¬ 
base systems. The prototype Object-Oriented Interface evaluated in this thesis fully sup¬ 
ported the complex EWIR database within the scope of its currently available features. We 
see no impediment to the further design and implementation of additional Objection-Ori- 
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ented Interface functionality. The cross-model accessing capability to the other non¬ 
object-oriented databases in the MODEMS is also recommended. 


C. THE EVALUATION OF THE OBJECT-ORIENTED EWIR DATA¬ 
BASE 


As stated in Chapter I, a primary goal of this thesis is to determine whether the 
object-oriented EWIR database is more effective, efficient, and intuitive for managing 
complex electronic warfare data collections than the non-object-oriented EWIR database. 
The evaluation of the object-oriented EWIR database implemented on the Object-Ori¬ 
ented Interface yields the following conclusions: 

• The object-oriented specification is easier to understand than the existing hierar¬ 
chical structure. Data relationships in the object-oriented specification are more 
naturally depicted and not subject to the user interpretation errors of the existing 
EWIR specification. 

• The Inheritance feature of object-orientation greatly simplified query construc¬ 
tion. Inherited attributes are available to a class without a requirement to explic¬ 
itly define either path statements or relations. 

• Accessing specific data elements via the path statement is a simple process. By 
referencing the object-oriented specification, path constraction is no more diffi¬ 
cult than following a “roadmap” that leads to the class or attribute of interest. 

• The construction of ad-hoc queries is quick and easy. This is due primarily to the 
ease of understanding the data relationships given a well designed specification. 
The inheritance, path, and object comparison features streamline the linkage of 
related data, thus simplifying query construction. 

The major complaint from the users of the existing EWIR data is the heavy reli¬ 
ance on the user’s understanding of the complex data relationships. From the user’s per¬ 
spective, the object-oriented paradigm is proven to be a superior method of modeling data. 
It naturally follows that a well designed object-oriented specification of a database would 
enhance user understanding. 

This thesis demonstrated that the object-oriented specification of the EWIR data 
produces a data model that more accurately reflects the true data relationships. This thesis 
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demonstrated that users with little prior knowledge of the EWIR data could take an object- 
oriented specification and construct a live EWIR database that is accurate in its EWIR data 
definition. This thesis demonstrated that with little prior knowledge of EWIR, users can 
quickly construct and execute ad-hoc queries. In summary, a good object-oriented EWIR 
database specification implemented on a proven object-oriented database system is a via¬ 
ble and preferred option from the perspective of database users. 
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APPENDIX A. THE EWIR SPECIFICATION 


The figures presented in this appendix are the object-oriented specification of the 
existing EWIR database as presented in Ref. 1. This appendix is used to assist in the com¬ 
parison of the EWIR specification of Ref. 1 with the derived subset of EWIR as specified 
in Chapter III of this thesis. 
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APPENDIX B. THE NEW EWIR DATABASE DATA DICTIONARY 
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# 

MAX_CHANGE 

s 

spec_va 

ref 

@ 

Signal 

# 

OID 

s 

# 

SCON_PWR 

s 

const_p 

ref 

# 

SN_CON_PWR 

s 

n_con_p 

ref 

@ 

Text_da 

# 

OID 

s 

# 

TEXT_DPT 

s 

# 

TEXT_COM 

s 

comment 

ref 

# 

TEXT_DSP 

s 

data_ds 

ref 

@ 

Rf_l_st 

# 

OID 

s 


# 

# 

DB3_S_WIDTH 

OID_RF_N_CO 

s 

s 

spec_va 

rf_n_co 

ref 

inherit 

# 

# 

TXMITTER.TYPE 

AGT_F_CORREL 

s 

s 

text da 

text_da 

ref 

ref 

@ 

@ 

Pulsed 

Disc ag 

# 

# 

OID 

OID 

s 

s 

# 

# 

OID.SIGNAL 

OID_PUL_RF 

s 

s 

signal 

pul_rf 

inherit 

inherit 

# 

# 

COHERENCE 

MOD_WAVEFORM 

s 

s 

rf_l_st 

text_da 

ref 

ref 

@ 

# 

Rf n CO 

RF_LIMITS 

# 

s 

OID 

val_ran 

s 

# 

ref 

# 

NO_DISC_STEPS 

OID_PULSED 

s 

s 

spec_va 

pulsed 

ref 

inherit 

@ 

# 

Warm 

DUMMY 

# 

s 

OID 

s 

@ 

Pul rf 

ff 

# 

PROB_CODE 

OID 

s 

s 

@ 

Rf eccm 
# 
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OID 

s 

# 

OID_WARM 

s 

warm 

inherit 

# 

RF_DISC_AGILITY 

set_of 

disc_ag_rf_eccm 

store 

@ 

Disc_ag_rf_eccm 

# 

OID 

s 

# 

OID_DISC_AG 

s 

disc_ag 

asc 

# 

OID_RF_ECCM 

s 

rf_eccm 

asc 

@ 

Polariz 

# 

OID 

s 


# 

POLAR_DATA 

s 

@ 

C_el_po 

# 

OID 

s 


# 

OID_RF_N_CO 

s 

rf_n_co 

inherit 

# 

AGT_F_CORREL 

s 

text_da 

ref 

@ 

Disc_ag 

# 

OID 

s 

# 

OID_PUL_RF 

s 

pul_rf 

inherit 

# 

MOD.WAVEFORM 

s 

text_da 

ref 

# 

RF_LIMITS 

s 

val_ran 

ref 

# 

NO_DISC_STEPS 

s 

spec_va 

ref 

@ 

Warm 

# 

OID 

s 

# 

PROB_CODE 

s 

@ 

Rf_eccm 

# 


# 

OID_POLARIZ 

s 

polariz 

inherit 

# 

SENSE 

s 

text_da 

ref 

# 

AX_RATIO 

s 

spec_va 

ref 

@ 

Scan 

# 

OID 

s 

# 

SMP_AVG_TIME 

s 

spec_va 

ref 

# 

THRESHOLD_MEAS 

s 

spec_va 

ref 

# 

PLANE_SCAN 

s 

text_da 

ref 

@ 

Mech_sc 

# 

OID 

s 

# 

OID_SCAN 

s 
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scan 

inherit 

# 

STP_CG_ABILITY 

s 

text_da 

ref 

# 

SC_FUNCTION 

s 

text_da 

ref 

@ 

Track 

# 

OID 

s 


# 

PLANE_TRACK 

s 

text_da 

ref 

@ 

Mech_tr 

# 

OID 

s 


# 

OID_TRACK 

s 

track 

inherit 

# 

MAX_R_AZ 

s 

val_ran 

ref 

# 

MAX_R_EL 

s 

val_ran 

ref 


@ 

Sector 

# 

OID 

s 


# 

OID_MECH_SC 

s 

mech_sc 

inherit 

# 

SEC_TYPE 

s 

text_da 

ref 

# 

PER_LIMITS 

s 

vaLran 

ref 

# 

SEC_W_AZ 

s 

spec_va 

ref 

# 

SEC_W_EL 

s 

spec_va 

ref 

# 

SM_TRACK 

s 

mech_tr 

ref 

@ 

Rad_pat 

# 

OID 

s 


# 

ANT_GAIN 


s 

spec_va 

ref 

@ 

Directi 

# 

OID 

s 


# 

OID_RAD_PAT 

s 

rad_pat 

inherit 

# 

BWDTH_AZ 

s 

spec_va 

ref 

# 

BWDTH.EL 

s 

spec_va 

ref 

# 

FIRST_AZ 

s 

spec_va 

ref 

# 

FIRST_EL 

s 

spec_va 

ref 

# 

SEC.CHAR 

s 

sector 

ref 

@ 

Antenna 

# 

OK) 

s 
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# 

ANT_TYPE 

s 

text_da 

ref 

# 

ANT_FUNCnON 

s 

text_da 

ref 

# 

HOR_DIMENSION 

s 

spec_va 

ref 

# 

VERT_DIMENSION 

s 

spec_va 

ref 

# 

AC_EL_POL 

s 

c_el_po 

ref 

# 

ANT.DIREC 

s 

directi 

ref 

# 

ANTEN_EMIT 

inverse_of 

emitter.ant_comp 

store 

@ 

Doper_p 

# 

OID 

s 


# 

COH_PCESS_INT 

s 


spec_va 

text_da 

ref 

ref 

# 

# 

NUM_PULSES_CPI 

SIG_PROCESSOR 

s 

s 

spec va 

sig pee 

ref 

ref 

@ 

# 

Sig pee 

AD_SECnON 

# 

s 

ODD 

a_d_con 

s 

ref 

@ 

Emitter 

# 

# 

DOPPLER.CALC 

OID 

s 

doper_p 

s 

ref 


@ 

# 

A d con 

UNIQUE_ID 

# 

s 

OID 

elnot 

s 

ref 

# 

ERF.ECCM 

# 

s 

AD_SAMP_PERIOD 

rf_eccm 

s 

ref 

spec_va 

# 

ref 

REC.COMP 

# 

set_of 

CONV_TRIG_METHO 

receive_emitter 

s 

store 

text_da 

# 

ref 

ANT.COMP 

@ 

set_of 

Receive 

antenna_emitter 

# 

store 

OID 

# 

s 

ECON_PWR 

set_of 

const_p_emitter 

# 

store 

RECEIVER_TYPE 

# 

s 

EN_CON_PWR 
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set_of 

n_con_p_emitter 

store 

# 

EDIS.AGILITY 

set_of 

disc_ag_emitter 

store 

# 

WEAP_SYSTEM 

s 

text_da 

ref 

# 

EMIT_FUNCTION 

s 

text_da 

ref 

# 

EMIT_PTF_GEN 

s 

text_da 

ref 

@ 

Receive_emitter 

# 

OID 

s 


# 

OID.RECEIVE 

s 

receive 

asc 

# 

OID.EMITTER 

s 

emitter 

asc 

@ 

Antenna_emitter 

# 

OID 

s 


# 

OID_ANTENNA 

s 

antenna 

asc 

# 

OID_EMITTER 

s 

emitter 

asc 

@ 

Const_p_emitter 

# 

OID 

s 


# 

OID_CONST_P 

s 

const_p 

asc 

# 

OID_EMITTER 

s 

emitter 

asc 

@ 

N_con_p_emitter 

# 

OID 

s 


# 

OID_N_CON_P 

s 

n_con_p 

asc 

# 

OID_EMITTER 

s 

emitter 

asc 

@ 


Disc_ag_emitter 

# 

OID 

s 


# 

OID_DISC_AG 

s 

disc_ag 

asc 

# 

OID_EMITTER 

s 

emitter 

asc 

$ 
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APPENDIX C. THE EWIR TEMPLATE FILE 


EWIROODB 

39 

4 

Elnot 

TEMPs 

OIDs 

ELINT_NOTATION s 
EMIT.SYSTEM s 

4 

Data_ds 

TEMPs 

OIDs 

CTRIB.AGENCY s 
LAST_UPDATE s 

3 

Comment 

TEMPs 

OIDs 

COMT_DATA s 

5 

Num_dat 
TEMPs 
OIDs 
UNITS s 
NUM_COM s 
NUM_DSP s 

4 

Spec_va 

TEMPs 

OIDs 

OID_NUM_DAT s 
VALUES 

5 

Val_ran 

TEMPs 

OIDs 

OID_NUM_DAT s 
LWR.VALUE s 
UPR.VALUE s 
5 

Trans_p 

TEMPs 

OIDs 

TX_LS_TX s 
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PK_PW_RAD s 

PK_PW_TXMITTER 

4 

Const_p 

TEMPS 

OIDs 

OID_TRANS_P s 
TTO_SWITCH s 
4 

N_con_p 

TEMPS 

OIDs 

OID_TRANS_P s 
MAX_CHANGE s 

4 

Signal 
TEMP s 
OIDs 

SCON_PWR s 
SN_CON_PWR s 

5 

Text_da 

TEMPS 

OIDs 

TEXT.DPT s 
TEXT.COM s 
TEXT_DSP s 
4 

Rf_l_st 

TEMPS 

OIDs 

DB3_S_WIDTH s 
TXMITTER_TYPE s 
4 

Pulsed 

TEMPS 

OIDs 

OID_SIGNAL s 
COHERENCE s 
4 

Rf_n_co 

TEMPS 

OIDs 

OID_PULSED s 
DUMMY s 
4 



Pul_rf 
TEMP s 
OIDs 

OID_RF_N_CO s 
AGT_F_CORREL s 
6 

Disc_ag 

TEMPS 

OIDs 

OID_PUL_RF s 
MOD_WAVEFORM 
RF_LIMITS s 
NO_DISC_STEPS s 
3 

Warm 

TEMPs 

OIDs 

PROB_CODE s 

3 

Rf_eccm 

TEMPs 

OIDs 

OID_WARM s 

4 

Disc_ag_rf_eccm 

TEMPs 

OIDs 

OID_DISC_AG s 
OID_RF_ECCM s 
3 

Polariz 
TEMP s 
OIDs 

POLAR_DATA s 

5 

C_el_po 

TEMPs 

OIDs 

OID_POLARIZ s 
SENSE s 
AX_RATIO s 
5 

Scan 
TEMP s 
OIDs 

SMP_AVG_TIME s 







THRESHOLD_MEAS s 
PLANE.SCAN s 
5 

Mech_sc 

TEMPS 

OIDs 

OID_SCAN s 
STP_CG_ABILITY s 
SC_FUNCTION s 
3 

Track 

TEMPS 

OIDs 

PLANE_TRACK s 
5 

Mech_tr 

TEMPS 

OIDs 

OID_TRACK s 
MAX_R_AZ s 
MAX_R_EL s 
8 

Sector 
TEMP s 
OID s 

OID_MECH_SC s 
SEC_TYPE s 
PER_LIMITS s 
SEC_W_AZ s 
SEC_W_EL s 
SM_TRACK s 
3 

Rad_pat 

TEMPS 

OIDs 

ANT_GAINs 

8 

Directi 

TEMPS 

OIDs 

OID_RAD_PAT s 
BWDTH_AZ s 
BWDTH_EL s 
FIRST.AZ s 
FIRST_EL s 
SEC_CHAR s 




8 

Antenna 

TEMPS 

OIDs 

ANT_TYPE s 
ANT_FUNCTION s 
HOR_DIMENSION s 
VERT_DIMENSION s 
AC_EL_POL s 
ANT_DIREC s 
4 

Doper_p 

TEMPS 

OIDs 

COH_PCESS_INT s 
NUM_PULSES_CPI s 

3 

Sig_pce 

TEMPS 

OIDs 

DOPPLER_CALC s 

4 

A_d_con 

TEMPS 

OIDs 

AD_SAMP_PERIOD s 
CONV_TRIG_METHO 

5 

Receive 

TEMPs 

OIDs 

RECEIVER.TYPE s 
SIG_PROCESSOR s 
AD.SECnON s 
7 

Emitter 
TEMP s 
OIDs 

UNIQUE_ID s 
ERF_ECCM s 
WEAP_SYSTEM s 
EMIT_FUNCTION s 
EMIT_PTF_GEN s 
4 

Receive_emitter 

TEMPs 






OIDs 

OID_E^CEIVE s 
OID_EMITTER s 
4 

Antenna_emitter 
TEMP s 
OIDs 

OID.ANTENNA s 
OID_EMITTER s 
4 

Const_p_emitter 

TEMPS 

OIDs 

OID_CONST_P s 
OID.EMITTER s 
4 

N_con_p_emitter 
TEMP s 
OID s 

OID_N_CON_P s 
OID.EMITTER s 
4 

Disc_ag_emitter 

TEMPS 

OIDs 

OID_DISC_AG s 
OID_EMITTER s 
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